Claude finished @erickgonzalez's task in 1m 7s —— View job

Rollback Safety Analysis

• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against all unsafe categories
• Apply appropriate label and post findings

Result: ✅ Safe to Roll Back

The label AI: Safe To Rollback has been applied.

Analysis

The PR contains two logical changes. Neither matches any rollback-unsafe category.

1. ImportStarterUtil.java — Stop skipping DEFAULT variant during starter import

The change removes a special-case VariantAPI.DEFAULT_VARIANT.name().equals(v.name()) guard from the import loop and relies solely on the variantFactory.get(v.name()).isPresent() idempotency check instead (dotCMS/src/main/java/com/dotmarketing/util/starter/ImportStarterUtil.java, lines 603–614).

• No DB schema change — no ALTER TABLE, ADD COLUMN, DROP COLUMN, or runonce task.
• No data model version bump — ImmutableContentlet.CURRENT_MODEL_VERSION is untouched.
• No ES mapping change — no changes to ESMappingAPIImpl, ESMappingConstants, or any field type mapping.
• No PK restructuring — the variant table's primary key is unchanged; the existing variantFactory.save() path is used with the pre-existing get().isPresent() duplicate guard, so it is fully idempotent.
• Rollback behavior: If rolled back to N-1, the old code resumes skipping the DEFAULT variant during import. A fresh install with an experiment-containing starter would revert to the startup-abort bug that this PR fixes — but that is a forward-compatibility issue (N-1 broken again), not a rollback safety issue. N-1 database and index state are unaffected.

2. CUSTOM_STARTER_URL / DOTCMS_STARTER_URL bumps (20+ docker-compose / README files)

All changes are documentation and configuration reference updates — URLs in comments or example YAML files pointing at a newer starter artifact (20260629). These carry no runtime storage contract changes whatsoever.

Quick-reference check against all categories:

🤖 dotBot Review (Bedrock)

Reviewed 26 file(s); 2 candidate(s) → 2 confirmed, 0 uncertain (unverified, kept for review).

Confirmed findings

• 🟠 High dotBackendOnboarding.md:198 — Starter URL uses incorrect future date
  The URL in dotBackendOnboarding.md references 20260629 which appears to be a typo for 20240629. This date format (YYYYMMDD) suggests June 29, 2026 - 2 years in the future from current date - making the starter file unavailable and breaking fresh installs using CUSTOM_STARTER_URL.
• 🟡 Medium dotCMS/src/docker-compose/local-run/docker-compose.yml:56 — Potential future-dated starter URL in example
  The commented CUSTOM_STARTER_URL example uses 20260629 which appears to be a typo (2 years future-dated from original 2024 examples). While commented, this could mislead users into configuring an invalid/nonexistent starter URL. PR context mentions updating to 'latest starter version' which would logically use a 2024 date, making 2026 likely erroneous.

_{us.deepseek.r1-v1:0 · Run: #28405946285 · tokens: in: 65646 · out: 13496 · total: 79142 · calls: 32 · est. ~$0.162}

@claude create a description for this PR

Claude finished @erickgonzalez's task in 39s —— View job

Tasks

• Read changed files for context
• Craft PR description

PR Description

fix(maintenance): import DEFAULT variant so experiment starter restore works

Summary

Fixes a fatal startup error when restoring a starter that contains A/B experiments. Before this fix, booting from such a starter would abort with:

Cannot construct instance of `com.dotcms.experiments.model.TrafficProportion`,
problem: Invalid Variants provided

Root Cause

There is an initialization ordering gap in MainServlet.init():

Every experiment's trafficProportion holds a reference to the DEFAULT variant. When ImportStarterUtil deserializes an Experiment, AbstractTrafficProportion's @Value.Check immediately validates that every referenced variant exists via VariantAPI.get(...). Because the old import code was explicitly skipping the DEFAULT variant and postgres.sql does not seed it, the DEFAULT variant was absent at deserialize time — validation failed and startup was aborted.

Fix

Stop skipping DEFAULT in the variant import branch — import it from the starter like any other variant (ImportStarterUtil.java, variant block, lines 599–615). The existing variantFactory.get(v.name()).isPresent() guard already prevents PK violations and makes the upsert a no-op when DefaultVariantInitializer has already run. With DEFAULT (and all experiment variants) present before experiments are deserialized, AbstractTrafficProportion validates successfully and ExperimentsFactory.save() completes as designed.

The fix stays entirely within ImportStarterUtil and uses the factory layer (no raw SQL).

Also Included

Bumps CUSTOM_STARTER_URL references to the latest starter version (20260629) across all docker-compose examples, documentation, and CLI test resources. This ensures new deployments initialize from a starter that exercises the fixed code path.

Changed Files

How to Test

1. On an instance with at least one A/B Experiment, generate a starter via _downloadStarter or _downloadStarterWithAssets.
2. Point a fresh install at that starter (e.g. via CUSTOM_STARTER_URL) and start dotCMS.
3. Before fix: startup aborts with Invalid Variants provided.
4. After fix: startup completes, experiments and their variants are present and open correctly in the UI.

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request